test(shape-inference): bump the catalog pin #1860 moved but did not update - #1873

…tative (salvages #1873) (#1882)

Salvage of #1873, which was closed unmerged when #1870 fixed the same
red first. **The count fix landed; this half did not — and it is the
more durable half.**

Credit where it is due: the diagnosis and the idea are Resch's, from
#1873. He is co-author on the commit. #1870 and #1873 independently
arrived at the same 221/266, which is the best confirmation those
numbers are right that two people can produce.

## What is missing today

The catalog pin blocked `Fast (Linux x86_64)` — a required check — on
`main` and on every open PR for 80 minutes, and the entire diagnostic
was:

```
assertion `left == right` failed
  left: 221
 right: 220
```

Nothing there says which number is the **live registry** and which is
the **pin**. So the reader cannot distinguish:

- someone added a handler and forgot the pin *(what actually happened)*,
from
- a registration disappeared *(a real defect, opposite fix)*,

and cannot tell which of the two numbers to trust. Resch put it well on
#1873: *"`left: 221, right: 220` with no indication of which side is
authoritative is a poor signal for something that blocks the whole
repo."*

RULES.md §1 asks every failure to say what failed, why, and how to fix
it. A test that can red the entire repository is exactly where that
obligation bites hardest, and this one was doing the bare minimum.

## What this changes

Both assertions now:

- name `left` as the live registry and `right` as the pin, so the
orientation is explicit;
- say to repin to `left` **in the same commit** and cover the new rule
with a test (§8) — which is the specific thing #1860 missed;
- state that the entry count does **not** always move in step with the
operator count. One operator can carry several opset-versioned entries,
so "+1 each" is a guess. It happened to hold for #1860; it will not
always.

That last point is not hypothetical: I obtained 266 by bumping the
operator count, re-running, and reading `entry_count`'s reported value
off the failure. The message now tells the next person to do that
instead of assuming.

## Verified by reproduction, not by reading

An assertion message is a claim about orientation, and it is trivially
easy to write one that is backwards. I reproduced #1860's exact scenario
— registered one extra operator against the current pin:

```
assertion `left == right` failed: shape-inference operator count moved:
`left` is the live registry, `right` is this pin. [...]
  left: 222
 right: 221
```

`left` moved with the registry, `right` stayed at the pin. The
orientation the message claims is the orientation the failure has, and
"repin to `left`" is the correct instruction.

## One trap worth passing on

My first "reverted control" run came back **FAILED with `left: 222`** on
a source tree that `git status` showed as clean, and `grep -c
PrisSimulatedNewOp` confirmed at 0.

The revert was `cp` → edit → `mv` back. `cp` stamps the copy with the
copy time, `mv` preserves it, so the restored file landed with an mtime
**older** than the test binary built from the mutated version. Cargo
compared mtimes, concluded nothing had changed, and re-ran the stale
binary. `touch` + rerun: 281 passed / 0 failed.

Relevant to anyone running mutation batteries, and the dangerous
polarity is the opposite of the one I hit. I got a false **FAIL**, which
is loud. The same mechanism produces a false **SURVIVED** — a mutation
reported as "the test cannot see this" when the binary under test never
contained the mutation at all. That is silent, and it corrupts a
battery's central claim. Restore by rewriting the file (which stamps
mtime *now*), not by `mv`-ing a copy back.
`.validation-worktrees/pris_1860_mutations.py` uses `write_text` for
both directions and is not affected; I checked rather than assumed.

## Validation

Under `scripts/hostlock.sh run --gate 8`, `taskset -c 16-23`,
`--test-threads=2`:

```
cargo fmt --all -- --check                                              clean
cargo clippy -p onnx-runtime-shape-inference --all-targets -D warnings  0 warnings
cargo test -p onnx-runtime-shape-inference                              281 / 43 / 16 / 1 / 1, 0 failed
```

Test-only, one file, no production code. Normal auto-merge, no bypass.

Co-authored-by: Pris <pris@squad.local>
Co-authored-by: Resch <resch@squad.local>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ded (#1939)

## What

`CUDA compile (Linux x86_64)` is red on `main` (reproduced at
`d3bf2ebaa`, and on `origin/main` locally with no changes applied). The
failing step is **Audit CUDA kernel capture-sync contract**, not the
honesty script:

```
---- unconditional_syncs_are_limited_to_capture_unsupported_paths ----
assertion `left == right` failed
  left  has "multi_head_attention.rs::execute"
  right does not
```

#1913 implemented `com.microsoft::MultiHeadAttention`. Its `execute`
drains the trailing transpose before returning per-call scratch to the
allocator pool, which is an unconditional `synchronize()`. The pin that
exists to notice exactly that was not updated.

## Why bumping the pin is the right fix here

I checked that the delta is **accounted for** rather than just making
the assertion pass — a pin you bump reflexively is worse than no pin.

1. **The delta is exactly one entry, added, with none removed.** Both
sets are otherwise identical.
2. **It comes from exactly one commit.** `git log --
src/kernels/multi_head_attention.rs` is a single commit, #1913
(`027e0cfb8`).
3. **It satisfies the pin's own stated admission rule.** The comment
above `expected` reads: *"Every entry is a path whose `capture_support`
is explicitly `Unsupported`, or a dynamically-admitted kernel's fallback
path that `capture_support` rejects."*
`MultiHeadAttentionKernel::capture_support` returns:

   ```rust
   CaptureSupport::unsupported(
"cuda_ep MultiHeadAttention uses the per-call Phase-2a workspace path
(allocates scratch and synchronizes)",
   )
   ```

So the kernel is already excluded from graph capture; the sync cannot be
captured because the path cannot be.
4. **It is structurally the same as an entry already in the list.**
`packed_varlen_attention.rs::execute` is admitted for the identical
reason — trailing stream synchronize on a path declared `unsupported`.
This is not a new category.

So: a pin that fell behind a deliberate change, not a regression in
capture behaviour. The entry carries its justification inline so the
next reader doesn't have to re-derive it.

## Verification

- **Positive control, already observed:** the pin *did* fire on a real
behavioural change. That is the test working, not failing.
- After this change: `test result: ok. 1 passed; 0 failed`.
- Reproduced the failure on `origin/main` with zero local modifications
first, to establish it was not mine.
- `cargo fmt --all -- --check` clean.

## How it went unseen, which is the part worth fixing

The CUDA lane has been red more or less continuously this week — #1881,
#1911, #1920, #1927 — so a lane that was **already failing** absorbed a
new failure without anyone learning anything from the colour. Resch hit
the identical shape with the `op_rules` count pin (#1873), and Gaff with
a grep-based falsifier that couldn't distinguish the case it claimed to
detect.

That is an argument for the pre-merge source scan in #1920 rather than
for more diligence: a check nobody can read the output of is not a
check.

Unblocks #1920. Part of #1875.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>